[Report]AWS관리형 서비스를 활용하여 Kubernetes를 위한 Devops환경 구축하기 #AWS Summit Online Korea

Classmethod 주식회사의 신입 엔지니어 김승연이라고 합니다. 이번 AWS Summit Online Korea에 참가해서 AWS관리형 서비스를 활용하여 Kubernetes를 위한 Devops환경 구축하기의 세션을 한번 정리해 보았습니다.

Speaker

Speaker: 강승욱

솔루션즈 아키텍트,AWS

Devops란

Devops란 이번 세션에서도 설명하고 있지만 많은 의미를 내포하고 있습니다. 하지만 간단하게 설명하자면 개발과 운영이 합쳐진 소프트웨어 개발 방법 중 하나입니다.

왜 Devops인가 Devops가 주목 받는 이유에 관해서 4가지 항목으로 정리 했습니다.

• 오늘날의 성공 요인은 속도와 민첩성
• 피드백을 받고 분석 하는 속도가 빨라질수록 고객에게 빨리 접근
• 비용절감이 가능할 수록 새로운 아이디어를 실험 가능
• 새로운 아이디어를 시장에 빠르게 낼 수 있으면 성공 가능성도 높아짐

하지만 이런 Devops를 수행하는 것은 힘든 일입니다.

• Continous Integration: 지속적인 통합(예 git등을 통한 코드의 통합) 으로 품질을 유지 하는방법
• Continous Delivery: 항상 신뢰 가능하게 배포될 수 있도록 지속적으로 관리하는 방법
• Agile Development: 순차적인 방법이 아닌 완성후 피드백을 받아 수정해 가며 더욱 완성도 높은 결과물을 만들어 내는 방법
• Continous Testing: 자동화 된 테스트 를 실행 하여 즉각적인 피드백을 얻는 방법
• Continous Integration 과 Continous Delivery를 합쳐서 CI/CD라고 합니다.

Devops는 꽤 폭넓은 개념입니다. 위의 4가지 요소를 위한 전반적인 관리가 필요합니다. 그래서 DevOps는 하드웨어 중심의 수작업이 아닌 코드를 통해 자동으로 인프라를 관리하는 데 주목하게 됩니다.

그리고 이것을 위한 코드로 관리하는 방법으로IaC(Infrastructure as Code)가 있습니다.

- IaC(Infrastructure as Code)

코드를 이용하여 대규모 서버 인프라를 관리하는 기술입니다.

- IaC가 주목받은 이유

• 개발자는 인프라로 옮기는 과정이 힘들어 인프라를 좀더 유연하고 변경가능 하기를 원했고 그래서 개발한 소프트웨어와 비슷한 방식으로 배포 구성 관리 할 수 있는 인프라를 원했습니다. 그에 따른 방법으로 코드로 인프라를 관리할 수 있는IaC가 주목받았습니다.

하지만 IaC실제로 수행하는 것은 굉장히 어려운 일입니다.

수많은 툴, 인프라, 어플리케이션 코드 모든 것을 IaC화 하기 위해서 개발자와 운영자 들이 생각을 하게 되었고 단순히 인프라 뿐만 아니라 어플리케이션 코드 까지 다 IaC화 해주는 방법으로 주목받은 것이Docker와Kubernetes입니다.

- 왜 Docker가 주목받았나?

• 개발자는 유연하고 변경가능 한 인프라를 원한다고 했습니다. container는 그에 따른 대안이 될 수 있습니다. Docker container는 그중에서 가장 인기가 있는 container기반 오픈소스 플랫폼 입니다. Docker container는 유연한 인프라 환경을 구성해 줍니다. 그뿐만 아닌 Docker는 코드로 관리할 수 있는 기능Dockerfile을 제공하고 있으며 애플리케이션과 인프라 환경을 같이 묶어서 빌드할 수 있게 함으로써 기존 개발방식의 문제점 중하나였던 개발 환경과 인프라 환경의 차이점으로 인한 문제를 해결 Devops를 실현 할 수 있었습니다. Kubernetes는 이런 Docker를 좀더 편리하게 쓸수 있는 방법 이라고 생각하시면 됩니다. 왜 Docker에서 Kubernetes가 필요한지에 대해서는 아래에서 설명하겠습니다.

Docker 와 Kubernetes

- Docker

Docker란 컨테이너 기반의 오픈소스 가상화 플랫폼 입니다. 기존 OS를 가상화 하는 방식이 아닌 하나의 서버에 여러개의 container를 실행하여 서로 독립적으로 실행하는 방식입니다.

• container:기존의 가상화는 달리 하나의 Host OS 위에서 프로세스가 동작하는 것 추가 적으로 설명하지면container는 Host OS입장에서는 하나의 프로세스 입니다. 하지만 사용자 입장에서는 기존의 가상화처럼 보이기도 합니다. container의 이런 특징으로 container가상화라고 부르기도 합니다.

• docker container의 특징

  • 원하는 개발 환경을 파일에 저장만 하면 os에 관계없이 해당 환경을 만들어줌
  • 환경들은 각기 독립적으로 존재하기 때문에 개별적으로 관리가 가능

- Kubernetes

container 오케스트레이션 툴 입니다. docker Host를 묶어 cluster로 관리하고 손쉽게 container를 배포 확장 관리를 해주며, 관리를 자동으로 해주는 서비스라고 생각하시면 됩니다.

cluster:1개 이상의 VM을 묶어 가용성 높게 서비스를 제공하는 VM의 집합체라 합니다. 여러대의 예를 들면 PC등을 묶어 하나의 시스템으로 동작하게 해주는 것이라고 생각하시면 됩니다.

Kubernetes에는 정말 많은 기능이 있습니다. 대표적으로 이런 기능이 있습니다.

• Service discovery와load balancing
  • container에 대한 트래픽이 많으면 kubernetes는 load balancing을 통해 트 래픽을 분산 하여 안정적인 운영이 가능하도록 합니다.
• Storage orchestration
  • kubernetes를 사용하면 로컬 저장소, 클라우드 등 원하는 저장소 시스템을 자동으로 탑재 할 수 있습니다.
• 자동화된bin packing
  • 서버 리소스(CPU,메모리(RAM)등)에 맞춰 컨테이너에게 쓸수 있도록 해준다.
• 자동화된Self-healing
  • kubernetes는 오류등을 일으키는 container를 시작하고 교체하는 등 의 자동화된 상태 체크를 함
• Secret과 구성관리
  • 암호,SSH key 와 같은 중요한 정보를 저장 관리 할 수 있음

- kubernetes가 필요한 이유

• 하나의 Node(예를 들면 AWS EC2)등에 Docker를 배포할 때에는 kubernetes를 사용할 이유는 없습니다. 하지만 container가 많아지고 container를 마이크로서비스 등으로 구성하면서 점점 kubernetes와 같은 오케스트레이션 툴의 도움이 필요해집니다. Kubernetes는 정말 많은 기능을 제공 하고 있습니다. 그중에서는 간단하게 다수의 container를 관리해주는 기능 부터 오류등을 체크 할수 있는 Self-healing기능 등 결국 kubernetes는 container를 관리해주며 사용자의 편리를 도울수 있고 이것이 kubernetes를 사용하는 이유입니다.

공식 문서에서는 사용이유를 이렇게 말하고 있습니다.

컨테이너는 애플리케이션을 포장하고 실행하는 좋은 방법이다. 프로덕션 환경에서는 애플리케이션을 실행하는 컨테이너를 관리하고 가동 중지 시간이 없는지 확인해야한다. 예를 들어 컨테이너가 다운되면 다른 컨테이너를 다시 시작해야한다. 이 문제를 시스템에 의해 처리한다면 더 쉽지 않을까? 그것이 쿠버네티스가 필요한 이유이다!

하지만 이런 도구들의 도입에는 문제가 많습니다.

문제점들은 설문을 통해 보실수 있습니다.

• 보안
• 전체시스템의 복잡도
• 모니터링
• 네트워킹
• 스토리지
• 로깅
• 인프라를 포함한 컨테이너의 스케일링
• 시스템의 가용성

이로인해 디지털 비즈니스에 핵심이 되는 빠른 변화에 집중하지 못하고 Kubernetes의 도입과 그를 위한 Devops환경구축 그리고 그에 대한 모든 인프라 구성에 고민을 해야되는 상황에 처하게 됩니다. 이 세션에서는 AWS의 다양한 컨테이너 관련 서비스를 통해서 어떻게 이런 문제를 해결 하려는지 알아보려고 합니다. -발표중-

Cluster Management For Kubernetes(Amazon EKS)

첫번째로는 Amazon EKS를 통해서 Kubernetes Cluster management를 하는 방법 -발표중-

Amazon에는 EKS라는 서비스를 제공 하고 있습니다.

EKS(Elastic Kubernetes Service)는 완전관리형의 Kubernetes 서비스입니다.

• EKS는 오픈소스 Kubernetes를 기반으로 하고
• Kubernetes위에 동작하는 모든 어플리케이션은 EKS에도 호환이 됩니다.

EKS를 사용하시면 4가지이의 이점을 얻으실 수 있습니다.

• 관리형 Kubernetes Control Plane 및 work node
  • Kubernetes의 Master Node 에 해당하는 부분을 EKS에서 관리
  • Kubernetes의 Worker Node 에 해당하는 부분을 EKS에서 관리
• 고가용성:EKS는 여러 AWS 가용 영역에 걸쳐 Kubernetes 관리 인프라를 실행하고 비정상 Control plane node를 자동으로 탐지하여 교체하고, 온디멘드에서 가동 중단 없이 업그레이드 및 패치를 제공합니다.
• 자동 버전 업그레이드:최신 Kubernetes 의 버전 업그레이드 등을 지원 하고 있습니다.
• 타 AWS 서비스들과의 통합:CloudWatch,Auto Scaling Groups,IAM,VPN 등과 긴밀하게 통합하여 운영할 수 있습니다.

지금부터 어떻게 AWS가 Kubernetes Cluster의 관리를 도와주는지 좀더 상세히 알아보도록 하겠습니다.

Control Plane과 Data Plane

본격적인 세션의 설명으로 들어가기 전에 Control Plane 과 Date Plane에 관해서 간단한 설명과 Kubernetes의 동작에 관한 설명을 넣어 보았습니다.

Control Plane이란

현재의 cluster 상태를 사용자가 원하는 cluster 상태로 만들어주는 것으로 Kubernetes가 cluster와 통신하는 방식을 담당 한다고 생각하시면 됩니다.

Data Plane란

Data plane 이란 container가 실행되고 네트워크에 연결될 수 있게 CPU,Memory,Network,stroage와 같은 능력을 제공하는 layer라고 합니다.

구성도를 통해서 더욱 자세히 설명해 보도록 하겠습니다.

- Control Plane 에 해당하는 구성도 입니다.

- Data Plane 에 해당하는 구성도 입니다.

- Kubernetes전체 구성도 입니다.(Kubenretes공식 문서의 구성도 입니다.)

• Kubernetes는
  • Mater Node: Kubernetes 시스템 을 관리 하는 Controler Plane을 운영하는 Node
  • Worker Node:실제 배포하고자 하는 애플리케이션이 올라가는 Node

로 구성되어 있습니다.

- Kubernetes 의 동작 Kubernetes의 동작은 복잡합니다. 동작에 관해서 간단하게 설명하겠습니다.

먼저 간단한 배포 방식 의 예입니다.

• Deployment를 만들고
• Deployment를 통해서 Replicaset를 만들고
• Replicaset에 의해 Pod를 생성

Deployment: 배포를 할때 어떻게 배포할 것인가를 관리해주는 역할

ReplicaSet: Pod를 여러개 복제하여 관리하는 역할

Pod: Kubernetes에서 배포할 수 있는 가장 작은 단위 Pod안에 container

가 포함 됩니다.

그에 따른 내부 생성의 순서 입니다.

먼저 kubectl으로 명령을 내립니다.

• kube-apiserver
  • etcd에 정보를 저장합니다.
• kube-controller
  • Deployment를 감지 -> ReplicaSet 생성
  • ReplicaSet 을 감지 -> Pod를 생성
• kube-scheduler는 Pod를 감지하고
  • 할당되지 않은 Pod가 있으면
  • 조건에 맞는 Node를 찾아 Pod를 할당합니다.
• kublet은 자신의 Node에 할당 되었으면 Pod가 있는지 체크
  • 없으면 Pod를 생성
  • Pod의 상태를 주기적으로 kube-apiserver에 전달합니다.

Kubernetes의 이런 복잡한 과정을 관리해준다라는 내용이 이후에 나올 내용입니다.

Phase 1 관리형 Kubernetes Control Plane 제공

• AWS에서의 컨테이너 옵션들

이미지와 같이 AWS에서는 EKS출시 이전 부터 EC2에 Docker Host를 만드는 것 부터 Kubernetes cluser 를 만드는 여러 방법을 지원 해 왔습니다.

다음은 EKS에서 제공하는 관리형 Control Plane에 대한 간단한 구성도 입니다.

• Single Tenant Amazon EKS Control Plane

• 구성
  • API서버의 앞단을 Load Balancer을 통해 구성
  • Control plane의 API서버가 이중화 되어 있음 -> Master Auto Scaling group 부분
  • cluster전체의 상태를 가지고 있는 Etcd cluster는 3중화가 되어 있음 -> Etcd Auto Scaling group 부분

어느 하나의 가용영역에 장애가 발생하더라도 자동으로 복구가 되어 가용성을 유지 할 수있습니다. AWS에서 관리하기 때문에 사용자는 편하게 cluster 관리가 가능합니다.

Phase 2 관리형 Kubernetes Data plane 제공

- 관리형 Workder Node기능 추가

• 관리형 work node기능
  • Amazon EKS 클러스터의 노드 프로비저닝 및 수명 주기 관리를 자동화
  • kubernetes 애플리케이션을 실행하기 위해 컴퓨팅 용량을 제공하는 Amazon EC2 인스턴스를 별도로 프로비저닝하거나 등록할 필요없음
  • 한 번의 조작으로 클러스터에 대한 노드를 생성,업데이트 또는 종료
  • 모든 관리형 노드는 Amazon EKS에 의해 관리되는 Amazon EC2 Auto Scaling 그룹의 일부로 프로비저닝 됨
  • 인스턴스 및 Auto Scaling 그룹을 포함한 모든 리소스는 AWS 계정 내에서 실행
  • 각 노드 그룹은 Amazon EKS 최적화 Amazon Linux AMI를 사용하며 정의한 여러 가용 영역에서 실행가능
• Amazon EKS Cluster를 프로비저닝 하는 방법

위와 같이 여러 기능을 이용하여 프로비저닝 할 수 있습니다.

- 완전 관리형 Data Plane 제공: Amazon Fargate for EKS

• AWS Fargate for Amazon EKS
  • 서버리스 Kubernetes container를 안전하고 안정적으로 대규모로 실행할 수 있는 방법
  • AWS에서 Kubernetes의 단순화된 배포, 관리 및 확장 가능
  • 기본적으로 모든 Pod에 대한 강력한 보안 격리
  • 응용 프로그램 구축에 집중 가능한 서버리스

고객 계정의 EC2인스턴스 에 Pod가 배포되지 않고 AWS가 관리하는 Fargate 컴퓨팅에 배포되기 때문에 Data Plane을 직접 관리할 필요가 없습니다.

AWS EKS Fargate로 인한 사용자 경험의 변화 입니다.

• 더 이상 할 필요가 없는 것들
  • Kubernetes Worker Node 관리
  • 사용하지 않는 유휴 자원에 대한 비용지불
  • Kubernetes Cluster Autoscaler
• 새롭게 가능하게 된 것
  • VM isolation at Pod level
  • Pod 단위의 과금
  • 멀티 테넌트 시나리오에서 손쉽게 비용절감
• 아직 할 수 없는 것들
  • Daemonsets 배포
  • (CLB/NLB)다른 서비스타입의 Load Balancer 사용
  • 권한을 부여한 Pod 실행
  • Stateful한 워크로드 사용

• Amazon EKS를 사용한 Worker Node구성
  • 관리형 Worker Node나 자가 관리형 Worker Node 사용 (Traditional container data plane)
  • stateless한 어플리케이션만 가지고 있다면 Fargate만 Worker Node로 사용 가능(Serverless container data plane)
  • Fargate 와 EC2 예약 인스턴스 및 스팟 인스턴스 옵션을 사용하여 비용 최적화를 동시에 이루고 싶은 경우에는 Faragte 와 EC2 Worker Node 를 동시에 사용할 수 있습니다.

• 관리형 Node group으로 구성한 아키텍처
  • Amazon EKS에서 관리하는 VPC(EKS Managed VPC)에 Single Tenant EKS Control Plane이 있습니다.
  • 고객이 관리하는(Customer Managed VPC)에 관리형 Worker Node가 3개의 가용역에 배포되어 고가용성을 확보 합니다.

CI/CD for Kubernetes(Amazon EKS)

두번째로는 아마존 EKS및 Kubernetes 위한 AWS의 CI/CD 환경 -발표중-

일반적으로 소프트웨어 릴리즈 프로세스를 정의할때

Continous integration, Continous delivery, Continous deployment는 앞의 왜 Devops인가 에 설명 하였기에 넘어가도록 하겠습니다.

CI/CD를 위한 AWS 개발툴

먼저 설명하기전 구성요소를 하나하나 보도록 하겠습니다.

• AWS CodePipeline
  • 빠르고 신뢰할 수 있는 애플리케이션 업데이트를 위한 지속적 전달 서비스
  • 소프트웨어 릴리즈 프로세스 모델링 및 시각화
  • 코드가 변경될 때 마다 빌드, 테스트, 배포
  • 타사 도구 및 AWS와 통합
• AWS CodeCommit
  • 안전한 Git기반 리포지토리를 hosting하는 완전 관리형 소스 제어 서비스
  • 공동 작업 - 코드를 쉽게 커밋, 분기 및 병합하여 팀 프로젝트를 쉽게 제어가능
  • Pull Request - Code Review를 요청하고 공동 작업자와 코드를 토론하는 메커니즘을 제공
  • AWS Management Console, AWS CLI 또는 AWS SDK 암호화-원하는대로 HTTPS 또는 SHH를 지원
  • 리포지토리는 고객 별 키를 사용하여 AWS KMS(AWS Key Management Service)를 통해 유휴시 자동암호화
• AWS CodeBuild
  • 소스 코드를 컴파일, 테스트, 패키징하는 완전 관리되는 빌드 서비스
  • 지속적으로 확장 미치 여러 빌드 동시 처리
  • 관리할 빌드 서버 없음
  • 사용한 컴퓨팅 리소스에 대해서만 분 단위로 과금
  • CloudWatch Events를 통해 빌드 모니터링
  • 각 빌드는 일관된 불변 환경을 위한 새로운 Docker container에서 실행
  • 모든 공식 CodeBuild 이미지는 Docker와 AWS CLI를 포함
  • Docker 이미지를 사용하여 사용자 요구에 적합한 사용자 지정 빌드 환경 제공
• Amazon ECR(ECR Container Registry)
  • 완전 관리형 Private Docker Registry
  • Docker Registry HTTP API V2 지원
  • 확장 가능, 고가용성, 고내구성 아키텍처
  • 보안: 암호화,IAM으로 액세스 제어
  • 이미지 수명주기 관리
  • 다른 AWS 서비스와 통합
  • Immuatable Image Tags 지원
  • Image Scanning 지원

기존 아키텍처에 CI/CD환경을 추가한 아키텍처 입니다. 이 아키텍처를 이용해서 앞서 있던 개발 순서를 설명하고 있습니다.

• 순서
  • Cloud9을 통해서 AWS CodeCommit에 code를 커밋하면
  • AWS CodePipeline은 이 커밋을 체크해서 새로운 Build를 실행함
  • AWS CodeBuild는 새로운 Build를 실행하여 어플리케이션과 container image를 빌드해서 AWS ECR에 Push를 함
  • AWS CodeBuild가 image push 가 끝나면 CodeBuild는 EKS Control Plane의 API Server에게 새로운 desire state로 새로운 버전의 Pod를 배포하라고 명령함
  • API Server는 각 Worker Node의 Kubelet에 새로운 Pod를 배포하라고 명령하고
  • 이 명령을 받은 Kublet들은 각 Worker Node에 설치되어 있는 Docker을 통해서 AWS ECR로 부터 새로운 image를 내려받아 Pod를 배포하게 됩니다.

Monitoring for Kubernetes(Amazon EKS)

마지막으로는 아마존 EKS및 Kubernetes 를 위한 AWS의 Monitoring 환경 -발표중-

- 필요한이유

아키텍처가 마이크로 서비스로 변하면 컴포넌트의 개수가 많아지고 컴포넌트간에 의존성이 높아 질 수록 서비스의 장애를 추적하는 일이 힘들어 집니다. 또한 기존의 VM환경에서 container로 환경이 변하면서 격리된 worker Node의 상태를 확인하는 것도 힘듭니다. 이런 상태를 확인하기 위해서 AWS에서는 크게 3가지 모니터링 요소를 추가했습니다.

구성요소를 하나하나 보도록 하겠습니다.

• Amazon CloudWatch Container Insights
  • 컨테이너 워크로드의 환경을 모니터링, 격리 및 진단 가능
  • 안정적이고 안전한 지표 및 로그 수집
  • 자동화된 요약과 분석
  • 지표,로그,트레이스 전반에 대한 가시성
  • 사전 생성된 대시보드
  • 로그 인사이트로 추가 분석 가능
  • FluentD DaemonSet으로 로그 수집
• Amazon CloudWatch Log Insights
  • container 워크로드의 환경의 로그를 어그레이션 및 분석
  • 로그 데이터를 대화식으로 검색 및 분석
  • 간단하고 강력한 명령을 포함한 특수 쿼리 언어 포함
  • 샘플 쿼리, 명령 설명, 쿼리 자동완성 및 로그 필드 검색 기능을 통해 손쉽게 쿼리 작성 가능
  • AWS 서비스 로그 및 로그 이벤트를 Json으로 출력하는 모든 어플리케이션및 커스텀 로그에서 필드 자동 검색 가능.
• AWS X-Ray
  • 프로덕션 분산 애플리케이션의 분석 및 디버깅
  • 성능의 병목 원인과 에러를 파악
  • 애플리케이션의 특정 서비스 이슈를 파악
  • 애플리케이션의 사용자에 대한 영향도 파악
  • 애플리케이션 서비스 호출 그래프 시각화 가능

기존 아키텍처에 Monitoring요소를 추가 했습니다.

• 장점
  • CloudWatch container lnsights를 통해 손쉽게 container의 상태를 확인 가능
  • CloudWatch Log Insights 를 통해 수집된 log를 분석 할 수 있습니다.
  • 어플리케이션의 성능 저하를 X-Ray를 통해 문제를 해결 할 수 있습니다.

Key take aways

kubernetes을 위해서 Devops를 하기 위한 광범위한 서비스를 제공

• Kuberneres Cluster Management: Amazon EKS
  • 관리형 Control Plane 제공: Amazon EKS
  • 관리형 Data Plane 제공: Amazon EKS (Self or) Managed node Group(On demand/RI/Spot)
  • 완전 관리형 Data Plane 제공: Amazon Fargate for EKS
• CI/CD tools for Kubernetes: Code Suites
  • CI/CD를 위한 Code Suites(AWS Code Pipeline, AWS Code Build, AWS Code Commit)
  • 완전 관리형 Container Image Registry: Amazon ECR
• Monitoring tools for Kubernetes: Cloud Watch & X-Ray
  • container 메트릭 측정: Cloud Watch container Insights
  • container 로깅: Cloud Watch Log Insights
  • 트레이싱: X-Ray

나름대로 설명을 추가해서 이번 세션을 정리해 보았습니다. Docker와 Kubernetes에 관해서 처음 접해보아서 여러가지 참고자료를 보면서 정리를 했지만 정리가 잘되었는지 잘모르겠습니다.

이번 세션정리가 도움이 되면 좋겠습니다.

참고자료

Devops란 무엇입니까?

Devops 구현 파트너 IaC를 구성하는 3가지 요소

docker란 무엇인가?

Kubernetes란?

Kubernetes시작하기-Kubernetes란 무엇인가?

AWS EKS

쿠알못이 Amazon EKS로 안정적인 서비스 운영하기